Every now and then I go back to doing something with Node.js, and when this happens I’ve already forgotten everything I did and all the little knowledge I acquired the previous time I used it. And I always have to start almost from the beginning again.
Two years ago I wrote about “How to get started with Node.js”: I think most of the information there are still valid… even the book Node.js in Action is still a MEAP (this time planned for release this month, August 2013).
This summer I’m planning on revising, during my holidays, the architecture of OpenROV, and given the huge number of people that are starting to use it, I want to inject" a bit more of “better ALM” in the mix, so I started to look around for coding conventions, development guidelines and how to do unit testing, continuous integration, build and so on: this post is a collection of some link that I found useful.
Coding and development guidelines
Here are some of the links I found useful.
- Felix’s Node.js Beginners Guide: written by Felix Geisendörfer, early contributor to Node.js, this is very short by “to the point” introduction to Node.js.
- Felix's Node.js Style Guide: still by Felix, a list of guidelines, ranging from how many spaces for a tab to closures and EventEmitters.
- Principles of Writing Consistent, Idiomatic JavaScript: A more detailed style guide, with more examples.
- Programming Styles in the Node Community: A comparison of the styles of 3 prominent node.js opensource developers: Ryan Dahl, creator of Node, Isaac Z. Schlueter, author of npm, and TJ Holowaychuk, author of Express (and more).
- Node.js: Style and structure: enough with JavaScript code writing guidelines, this guide focuses more on Node.js specific recommendations.
- Bulletproof Node.js coding: very opinionated list of suggestions, some probably dictated by preferences of the developer that wrote it, other more widely adoptable.
- Bootstraping a Node.js App for Dev/Prod Environment: Something that I really wanted to understand better was how to configure different settings based on the environment in which the application is running: production, development, testing and so on. This page gives some good advices on how to do it easily.
- Why use "closure"?, What is "this"?: two articles explaining in detail two fundamental concepts of JavaScript programming: this, and closures.
One common idea that comes out from those pages is that:
All code in any code-base should look like a single person typed it, no matter how many people contributed.
So, when starting a project, either open source or proprietary, write a style guideline, possibly striving for maximum readability, especially if it’s open source, and make sure every contributor agrees and then follows it.
Testing framework
A testing library I’m looking into experimenting with is Jasmine (or actually it’s node.js version jasmine-node): it’s a BDD framework and the syntax looks pretty intuitive and, if text descriptions are carefully chosen, the report is very human readable and describes very well what each test is doing.
The documentation of jasmine is well done, with samples of every aspect of the framework, and the wiki explains also how to use Jasmine with other frameworks. If you want to do some tests you can also try it directly online at: http://tryjasmine.com/
Other JavaScript testing frameworks are Mocha and QUnit, the framework used to test jQuery, jQueryUI and jQuery Mobile. To use this last one with Node.js you need to use its port on Node.js: node-qunit.
And while not strictly a testing framework and also not needed with Node.js, Karma is a test runner for JavaScript. Because probably your application also have some JavaScript that runs in the browser and integrates with the DOM.
CI and build
One service I’ve tried a few times, mainly for testing purposes, is Travis CI: it automatically pulls changes from GitHub and can build projects on most platforms (except .NET). To configure it all you need is adding a .travis.yaml file on your repository.
OpenROV is already being built on Travis-CI, but at the moment it only installs all the needed packages, so not very useful. But once I add some tests I think it will become more interesting to use.
I’ve also noticed that Travis-CI also picks up every pull requests and run the same set of tests, thus immediately verifying whether the pull request broke something or not.
Deployment
I usually deploy to Azure Websites, which can run Node.js without a problem. I gave a speech at the local node.js user group about how to deploy a MongoDB powered Node.js app on Windows Azure.
Conclusion
Let’s now see if I find the time to really build a prototype of the new structure of the OpenROV brain.
Do you have more links you want to share and think are useful? Please write a comment and I’ll add them to the post.